Tool Support for OCL and Related Formalisms - Needs and Trends

The recent trend in software engineering to model-centered methodologies is an excellent opportunity for OCL to become a widely used specification language. If the focus of the development activities is shifted from implementation code to more abstract models then software developers need a formalism to provide a complete, unambiguous and consistent model at a very detailed level. OCL is currently the only language that can bring this level of detail to UML models. The purpose of the workshop was to identify future challenges for OCL and to discuss how OCL and its current tool support can be improved to meet these challenges. The workshop gathered numerous experts from academia and industry to report on success stories, to formulate wishes to the next generation of OCL tools, and to identify weaknesses in the language, which make OCL sometimes cumbersome to use. The workshop could also attract numerous people whose aim was to get an overview on the state of the art of OCL tool support and on how OCL can efficiently be applied in practice. 1 Motivation and Goals Model-centric methodologies see modeling artifacts as the primary output of development activities and not implementation code, as it is currently the case in most software development projects. These new methodologies were triggered by recent standardizations of meta-modeling technologies, which have facilitated the syntactic and semantic specification of modeling languages. It has been reported in numerous case studies how model-centric approaches can yield a productivity leap and thus dramatically reduce development costs. Model-centric methodologies could, however, not become mainstream yet, because this would require a matured, seamless tool support for all development phases. One of today’s great challenges is to make modeling tools as powerful and easy to use as current Integrated Development Environments (IDEs) for programming languages. The Object Constraint Language (OCL) is a standardized, versatile, multipurpose specification language. It can bring a degree of preciseness to graphical models that is needed if the graphical models should become the primary artifacts in the development process. The pressure to improve the tool support for OCL goes along with the overall challenge to improve the quality of modeling tools in general. Improved tool support is just one thing that has to be addressed in order to increase the popularity of OCL. There are plenty of other questions this workshop was devoted to. The following list is a (surely incomplete) classification of questions that need to be answered. Technical questions on how to improve tool support for OCL There is a technical dimension how the community can effectively provide better OCL tool support. How can we facilitate the development of new tools? Which features should an OCL tool offer to encourage the usage of OCL in practice? Is it feasible to make OCL executable and to provide an animator for OCL? Should we strive for a common architecture of OCL tools which would enable us to reuse standard components, such as a parsing component? These and similar questions are discussed in the workshop papers [5–8]. The project described in [6] provides a new grammar for OCL that can be used as a starting point to build a parser (actually, the grammar has been already ’implemented’ in form of a parser). This is a remarkable step forward since the official grammar given in the OCL 2.0 language specification intentionally abstracts from ’implementation glitches’. Language issues The language specification for OCL has certainly improved over the last years, but there are still some debatable points in the OCL semantics. Furthermore, OCL is missing some constructs, e.g. a modifies clause, that are widely accepted in the specification language community and that are offered by other specification languages such as the Java Modeling Language (JML). The paper [9] strives to find a solution for the frame problem that has been highly neglected in OCL so far. The papers [8, 5] discuss besides the semantics of certain constructs also the general architecture of OCL. They try to classify the concepts according to their importance from the language architecture’s point of view. Based on this concept classification, the definition of OCL in syntax and semantics could be reorganized to make it more flexible and to define OCL rather as a family of languages than one, entirely fixed language. Usability questions and application examples Besides improved tool support and a clear and concise language description, OCL would also benefit from more convincing examples and application scenarios. The paper [3] applies OCL to make the terminology used by meta-modeling experts much more precise. So far, there was a rudimental common agreement among meta-modelers on what basic meta-modeling concepts are supposed to mean but this agreement has never been formalized beforehand. The paper [4] describes an approach to guide the user when writing OCL constraints. The paper shows how a widely-used class of OCL constraints can actually be generated by instantiating a schematic OCL constraint. This technique is especially suitable for software developers who write their first constraints and want to become familiar with the language.